home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 1
/
Cream of the Crop 1.iso
/
DESQVIEW
/
DVEVNT01.ARJ
/
4DV&PCB.TXT
next >
Wrap
Text File
|
1991-01-13
|
21KB
|
443 lines
4 PCBoard DESQView Nodes Plus LANtastic
---------------------------------------
by
Scott Howard
(801) 264-9711 (Hayes 9600)
(801) 264-9712 (A-J 9600 V.32)
(801) 264-9713 (US Robotics HST)
This document summaries my attempts to configure 4 PCBoard nodes
on one 386 machine using DESQView, along with connecting that
machine to a LANtastic network. Please note that the information
following will NOT work on a 286 machine because of the
difference in architecture between a 386 and a 286 machine. This
configuration requires the use of a 386 processor in order to
work along with QEMM or similar extended memory manager.
Hardware Used
-------------
386/25 Clone with 8 meg of memory (Node 2)
Everex EV-170 3 port serial card with 16550A UARTS installed
3 9600 high speed modems (all opening at 19200)
1 Parallel Port
1.2 meg and 720K floppies
150 Meg CDC ESDI hard disk
CGA Monitor
LANtastic Ethernet (16 Bit - AE2 style) board
286/10 AST Premium with 4 meg of memory (Node 1)
2 Serial and 2 Parallel Ports
1.4 meg and 1.2 meg floppies
RLL 60 Meg hard disk
120 Meg tape backup
VGA Monitor
Software Used
-------------
PCBoard 14.5/E6, MSDos, DESQView 2.31, QEMM 5.11, LANtasti 2.57U,
PC-Cache Disk Cache Software
Quick Summary
-------------
The final outcome of my attempt was successful - in a way. The
original plan was to run the 386 machine (Node 2) as the server
with 3 dial-in and 1 local-only PCBoard nodes - with the AST 286
machine accessing it. However, that did not work as you will
note later in this document. So, the 386 machine ended up being
a Node to the 286 machine with it (the 286) acting as the server.
All 4 PCBoard nodes on the 386 machine work fine. The network
runs fine as well. In summary, you can run multiple nodes on one
machine in conjunction with LANtastic without a problem - IF you
plan and tune your system accordingly and you DON'T try to run
DESQView on top of LANtastic's SERVER software.
Exact 386 Machine Hardware Summary
----------------------------------
IRQ2 LANtastic Ethernet Adaptor at 300H I/O Base
IRQ3 COM2 at 02F8
IRQ4 COM1 at 03F8
IRQ5 COM3 at 03E8 (DSZ Port # 8)
IRQ7 LPT1
Note that DSZ has a 'standard' port configuration of 03E8 and
IRQ5 as PORT #8 - which allows you to use the statement
SET DSZPORT=8
in your BOARD.BAT file for that node so that DSZ protocols will
function properly.
Exact 286 Machine Hardware Summary
----------------------------------
IRQ2 Tape Backup at 340H I/O Base
IRQ3 COM2 at 02F8
IRQ4 COM1 at 03F8
IRQ5 Mouse Port
IRQ7 LPT1 and LPT2 (sharing IRQ7)
IRQ10 LANtastic Ethernet Adaptor at 300H I/O Base
Note that it is possible to share LPT1 and LPT2 on IRQ7 at the
same time. Normally you only need to use IRQ5 for LPT3. This
will help you save an interrupt if necessary on a machine which
is short of interrupts and long on devices hanging from it.
Exact 386 Machine Software Summary
----------------------------------
CONFIG.SYS
device=c:\qemm\qemm.sys ram fr=cc00 nw3 tasks=48
shell=c:\command.com /p /e:256
buffers=4
fcbs=48,48
files=60
stacks=0,0
lastdrive=g
The QEMM line above does the following:
ram fills in low mem to 736K (due to CGA adaptor) and
allows use of high memory for loading device
drivers and other TRS programs
fr=cc00 sets the page frame to CC00 (just above the hard
disk controller). This resulted in the largest
HIGH RAM area available on my machine to just over
80K.
nw3 tells QEMM this machine is not running Windows 3.0
which frees up 4K of additional memory
tasks=48 sets the number of QEMM tasks in protected mode to
48
The 'stacks=0,0' statement frees up additional memory in low
mem. All other statements are pretty much self explanatory.
AUTOEXEC.BAT
@echo off
path c:\dos;c:\qemm; ....etc.
c:\qemm\loadhi c:\dos\share /f:4096 /l:60
c:\qemm\loadhi c:\dos\fastopen d:128 /x
c:\qemm\loadhi c:\bin\pc-cache /sizexp=4096 /max=34
c:\qemm\loadhi c:\lantasti\ae2 irq=2
c:\qemm\loadhi c:\lantasti\ailanbios run_burst=1
c:\qemm\loadhi c:\lantasti\redir n1
c:\qemm\loadhi ansi /s
dv
The AUTOEXEC.BAT file contains a 4 meg disk cache program
being loaded into high memory, along with SHARE, FASTOPEN, and
ANSI - which supports the @X PCBoard variables.
The LANtastic software is also loaded into high memory, with
one change to the normal calling sequence - and that is the
addition of the statement 'run_burst=1' on the AILANBIOS line.
What this does is to reduce the time LANtastic uses for
processing from 2 clock ticks down to 1 in order to give more
time to DESQView and its overall PCBoard operation.
DESQView on the 386 Machine
---------------------------
After loading in all of the above, CHKDSK yields the following
information on the 386 machine:
753664 total memory
690112 total bytes free
In other words, you have plenty of memory for very large DOS
partitions within DESQView *if* you also have a lot of system
memory to go along with it. If you are running a MONO screen,
your available low memory will be less. If you are running
either an EGA or VGA display, it will be even less still since
QEMM will not be able to 'fill-in' any video memory to use as low
DOS memory.
Next, DESQView loads and automatically loads 4 PCBoard nodes into
4 memory partitions. Nodes 1-3 are dial-in nodes, Node 4 is for
local maintenance use. Based on the total machine memory of 8
meg installed, and 4 meg of it being used for the hard disk
cache, the remaining 4 megs is then used by DESQView to set up
the 4 PCBoard partitions. After loading all four, DESQView's
memory status reports 1040K of total EMS memory still left, with
the largest partition being 656K. This is based on a partition
size of 512K for each node which will be shown later. In other
words, with 4 PCBoard nodes functioning, you still have
sufficient memory available for other windows as well. However,
I recommend you never open more than a total of 4 windows at any
one time while running this configuration with high-speed callers
on-line.
DESQView Main Configuration Parameters
--------------------------------------
The main DESQView startup parameters are set to 2 clock ticks for
both the foreground and background tasks.
CTRL+ALT+DEL has been set to reboot a window - NOT the machine.
The ability to reboot the machine within DESQView is disabled by
placing a '0' in the keyboard field. This is to prevent an
inadvertent reboot of the machine and also in most cases DESQView
on my machine will lock up if a system reboot is attempted. If a
hard lock occurs, it is necessary to press the 'RESET' key on the
CPU itself.
DESQView Performance Window:
Foreground Ticks: 2
Background Ticks: 2
Common Memory: 17K
DOS EMS Buffers: 16
Optimize Commun: N
Allow Swapping: Y
Manage Printers: N
Contrary to what you might think, since my system uses 16550A
UARTS, it is NOT necessary for DESQView to 'Optimize
Communications'. Since PCBoard will more than take care of that
with the 16550A's, you free up DESQView from yet another task it
has to perform by setting this to 'N'. CAUTION: You MUST be
using 16550A UARTS in order to do this. If you are not using
them, leave this set to 'Y'.
Each dial-in PCBoard node under DESQView is configured as
follows:
Screen 1: (Change a Program)
----------------------------
Program Name: PCB - N1 (or PCB - N2, etc.)
Keys to Open: A1 (or A2, etc. I use A1 to put them at
the top of the Open a Window menu.)
Memory Size: 512K
Program: BOARD1.BAT (BOARD2.BAT, etc.)
Directory: D:\PCB1 (or D:\PCB2, etc.)
Options:
Writes directly to screen: N
Displays graphics info: N
Virtualize text: T
Uses serial ports: Y
Requires floppy disk: N
Screen 2: (Change a Program Advanced Options)
---------------------------------------------
System Memory: 0
Max Memory: BLANK
Script Buff: 0
Max EMS Mem: BLANK (DV will use only what it needs)
Window Start: 25 (Start height)
80 (Start width)
0 (Start row)
0 (Start col)
Close on Exit: N (BOARD.BAT will take care of that)
Uses own color: Y
Allow Close: N (Don't allow close command since you
Runs in back: Y could leave files locked if you do!)
Uses Math Copr: N
Keybrd Conflict: 0
Share CPU fore: Y
Share EGA fore: N
Can be swapped: N
Protection Lvl: 0
All dial-in nodes use the above information. In the case of the
'local-only' node, the 'Runs in the background' field is set to
'N' instead of 'Y'. Since there is no COM port attached to this
node, and if required to open another window on top of it for
some reason, by placing a 'N' in this field, DESQView will halt
the execution of Node 4 during the time the other window is open
- placing less of a burden on your over-all system. The same is
true for other windows which I have set up - including a PCBMoni
window, a PCBFiler window, etc. All of these are set to 'N' in
the 'Runs in background' field so that they will not steal CPU
time if they are placed in the background for any reason.
Normally I strongly suggest completely closing any non-COMM port
window if you find it necessary to switch to a different window.
However, in the event you can't - at least this will not place an
additional burden on the CPU which you are off doing something
else.
Note that the 'Maximum EMS' is set to 0 since I do not use the
SET PCB=/SWAP statement in my respective BOARDx.BAT files due to
the fact that my partition size is 512K. With PCBoard running,
line 24 of my screen always shows in the area of 218K or higher
which is plenty for all SHELL functions without requiring a SWAP
of PCBoard to either EMS or disk memory. This really helps speed
things up on my system.
PCBoard 'BOARD.BAT' Notes
-------------------------
Since I have a 512K partition for each PCBoard node, it is not
necessary to include the SET PCB=/SWAP statement in my BOARDx.BAT
files to force PCBoard to swap out to disk or EMS memory during
SHELL functions. This means that SHELL functions run very fast
on my system.
Second, at the end of my BOARDx.BAT files I place the statement:
EXIT
so that I automatically close that PCBoard Node window when
pressing (F1) or (F10), etc. If you want to remain in that
window, then don't place the 'EXIT' statement at the end of the
file. I find it best to allow the batch file to go ahead and
close the window for me so I don't forget.
Overall Fiascos and Summary
---------------------------
Many days were spent trying to get the 4 PCBoard nodes to run
reliably on the 386 machine along with it (the 386 machine)
acting as the main file server for LANtastic. Seems that the
'up-time' would vary from 10 seconds to several hours before a
hard lock occurred. Many items were tried which did improve the
reliability of operation - but never to the point of allowing the
system to run unattended for long periods of time. The most
dramatic improvements came with the use of the 'run_burst'
statement associated with the AILANBIOS call. The default number
of clock ticks LANtastic assigns to itself when performing
LANBIOS functions is 2. This however, seemed to cause DESQView
to lock up quite fast. By setting both the server and the node
to a run_burst of 1, DESQView would run for a much longer period
of time before encountering a problem.
Second, it appeared that when slowing down the AST machine (which
of course at this time was acting as a node to the 386 machine),
from 10 mhz operation to 8 mhz, things got better. However,
simple COPY commands from the server to the 286 machine would
frequently fail and lock either or both machines. A call to
Artisoft solved that problem. Seems some older 286/386 machines
use bus timing which may be incompatible with the new LANtastic
ethernet boards. By setting jumper W8 on the LANtastic board to
pins 2-3 instead of 1-2, that problem went away. By changing
this jumper (new style boards only), you alter LANtastic's timing
to other than standard to basically accommodate higher speed
busses.
After trying virtually every combination possible, it became
apparent that only when the LANtastic SERVER software was loaded
would DESQView have a problem. If SERVER was not loaded - all
worked fine. A little digging into the DESQView manual confirmed
my conclusion:
Reference page 164 of the DESQView Manual
Appendix C: Using DESQView with a Network
"Many networks allow a machine to be used as both a
'normal' computer and as the network server at the same
time. DO NOT RUN DESQVIEW ON A SERVER MACHINE. To run a
machine as a server, a special, concurrent extension to DOS
is loaded. The server's concurrency and DESQView's
concurrency will interfere with each other and (most
likely) disable or crash your server."
So true! Hence, the bottom line is that you CAN run multiple
DESQView nodes (or windows) on top of LANtastic (or probably any
other network) as long as you DON'T try and also run that machine
as a server. Hmmm, so my plans had to change. Instead of
logging into the machine 386 machine from the 286 machine, would
it work for the 386 machine to log into the 286 machine which was
not running DESQView. Yup. However, a lot of the original items
which were planned had to be altered. I can of course copy
files, etc. from the 386 machine to the 286 machine as long as I
do it from inside a DESQView window on the 386 machine. Since
the tape backup resides on the 286 machine, it is necessary to
exit from DESQView completely and load in LANtastic's SERVER,
followed by logging into the 386 machine from the 286 machine in
order to perform a backup. After which I reboot the 386 machine
to remove SERVER from memory and reload DESQView and the PCBoard
nodes.
Is It Worth It?
---------------
The final question is "Is it worth it to set up such a
configuration?" In my case - yes. I don't need the speed of the
386 machine to perform other tasks I need to do such as working
on a spreadsheet or in my word processor. However, the storage
available on the 386 is essential. Although I can't directly
copy a file from the 286 machine to the 386 machine, I can slip
over to the other keyboard on the 386 machine and copy it from
the 286 machine to the 386 machine inside a small DV window -
even while the board is running.
Second, since it is physically possible to run 5 PCBoard nodes on
my 386, I could set up the 286 machine with a very large hard
disk and place another PCBoard node up on it if desired - making
the 386 nodes go to it for files. Sort of opposite of what I had
in mind to start with, but accomplishing basically the same
thing. Only requirement is that the main server can NOT run
DESQView on top of the LANtastic SERVER software. By using say
3-386 machines, one of which is acting as a server and the other
two as nodes, it would be possible to run as many as 7-9 nodes at
one time without much of a problem - allocating 3-4 PCBoard nodes
per 386 DESQView Node machine and 1 dial-in node for the main
server which was not running under DESQView.
The nice thing though is that I can reliably run 3 dial-in
PCBoard nodes on one machine - with a 4th node for local work as
well - while still having the capability of transferring files
between the two machines as necessary. In the event the hard
disk failed on the 386 machine, it would be fairly easy to switch
the nodes over to accessing files off the 286 machine.
I would not recommend trying such a configuration on other than a
20 mhz or faster 386 machine. Also, the number of PCBoard nodes
you plan to run on one machine will depend a lot of the number of
them which are running at 9600 bps or above. If you will be
running one or more 2400 bps nodes, no problem.
Disclaimer
----------
Hate to have to do this, but:
The information provided in this document is provided 'as-is'
without any warranty of any type or guarantee of fitness of use.
The information included simply summaries my success in
configuring my hardware to meet a specific application. Your
hardware and software may not function identically to mine and
you assume full responsibility for trying any of the above on
your system. I strongly suggest that before you attempt any of
the configuration items listed that you completely back-up your
system first.
Scott Howard